学会异常处理，让你的代码更稳定
The following article is from dingtingli Author dingtingli
How - 如何处理异常？
👉 欢迎加入小哈的星球 ，你将获得: 专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡
目前, 正在星球内部带小伙伴做第一个项目：前后端分离博客，手摸手，后端 + 前端全栈开发，从 0 到 1 讲解每个功能点开发步骤，1v1 答疑，直到项目上线。目前已更新了67小节，累计10w+字，讲解图：513张，还在持续爆肝中.. 后续还会上新更多项目，如秒杀系统, 在线商城, IM即时通讯等，戳我加入学习，已有200+小伙伴加入
正常流程 vs 异常流程
一个程序的运行是由许多函数的调用组成。函数 A 调用函数 B，函数 B 再调用函数 C，依次类推。
在正常情况下，每个被调用的函数都能返回调用者所期望的结果，使得程序可以顺畅地运行。我们可以将这种状态称为“正常流程”或“常规路径”。
然而，有时候，函数在执行过程中可能会遇到一些它无法解决的问题，这些问题会打破程序的正常流程，从而引发我们所称的“异常流程”。
例如，你可能试图访问一个已经被删除的文件（触发FileNotFoundException），或者由于递归层次过深导致栈溢出（触发StackOverflowException）。这些问题既可能由程序本身产生，也可能由外部环境导致。
异常流程的影响
异常流程往往给程序员带来极大的困扰。如果不对它们进行处理，我们就会收到一大堆的错误信息。
大家都熟知的 Windows 蓝屏现象，正是由于操作系统内核模块中出现了未经处理的异常所引起的。
在控制台应用程序中，未经处理的异常信息会直接在命令行界面中显示。
在图形界面的应用程序中，未经处理的异常则会通过弹窗的形式进行显示。
而在网页应用程序中，未经处理的异常信息会直接在页面上呈现。
这些未经处理的异常都有可能导致当前运行的程序崩溃。因此，如何正确处理异常是程序设计中必须要考虑的问题。
面向对象语言处理异常的原理
大部分的面向对象编程语言，都通过 exception 对象来处理异常流程。
异常的设计目的是用于表示程序中的错误条件，并在出现这种错误条件时通过抛出异常来改变程序的正常流程。
在这里，你可能会问：“为什么面向对象语言要分离异常流程和正常流程的控制流？”
其实，这主要是因为异常情况在本质上与常规程序执行流程不同。在常规流程中，函数返回的结果是预期的，而在异常流程中，函数无法正常执行，需要通过其他方式表达这种错误情况。
通过将异常流程和正常流程的控制流分离，我们可以使代码结构更清晰，易于理解和维护。同时，这也有助于提高代码的健壮性，因为在出现异常时，程序可以直接跳转到处理这个异常的代码块，而不是继续执行可能会导致程序崩溃的代码。
然而，异常并不是方法的返回值，那么异常是如何传播的呢？
实际上，在 C 语言中，异常流程仍然通过函数返回错误代码的方式来处理，也就是说，正常流程与异常流程是通过同一种控制流来处理的。
然而，对于 Java 和 C# 这类语言来说，异常流程和正常流程的控制流是分离的。运行环境会直接负责处理异常流程的控制流，使得异常对象可以直接回溯到处理它的函数中，而非仅能返回到调用它的函数。
具体流程如下：
每当执行一个方法，如果该方法抛出了异常，则该异常对象将被压入调用栈的顶部。
程序可以通过在方法内使用
try/catch块来捕获该异常。当捕获到异常时，该异常对象将从调用栈的顶部弹出，并被传递到catch块中处理。如果没有任何
catch块能够处理该异常，则该异常将继续在调用栈中传递，直到被某个catch块处理。如果未能捕获该异常，则该程序将终止并生成一个错误报告。
总的来说，异常是通过抛出异常对象，然后在调用栈中进行回溯传递，以此来表示程序中出现的错误或异常情况。
以下是异常的几种常见处理方式。我尽量让语言更流畅，逻辑更清晰，并检查了准确性。希望对你有所帮助。
异常处理：预防胜于治疗
异常处理涉及创建异常对象、填充栈跟踪信息，以及可能的上下文切换等步骤， 因此，与常规的控制流语句相比，异常处理机制的性能开销往往更大。频繁使用异常可能会对程序的性能产生负面影响。
然而，即使在高性能需求的场景下，我们也可以通过一些策略保持良好的性能。关键在于预防性地检查错误条件，避免在常规执行路径中抛出异常。
接下来，我将介绍两种预防性处理异常的策略：Tester-Doer 模式和 Try 模式。
Tester-Doer 模式
Tester-Doer 模式主要是为了防止在可能抛出异常的操作中造成不必要的性能消耗。
"Tester-Doer"模式由两个部分组成：
"Tester"（检查者）：负责检查某个操作是否能够成功执行。
"Doer"（执行者）：进行可能抛出异常的操作。
下面是这种模式的一个代码示例：
string filePath = "..."; // 文件路径
if (File.Exists(filePath)) // "Tester"
{
string content = File.ReadAllText(filePath); // "Doer"
Console.WriteLine(content);
}
else
{
Console.WriteLine("文件不存在");
}
在上述示例中，我们首先使用 File.Exists 方法检查文件是否存在。如果文件存在，我们接着使用 File.ReadAllText 方法读取文件内容。这样，我们就避免了在试图读取不存在的文件时引发异常，提高了代码的性能。
Try 模式
对于对性能特别敏感的 API，我们可以使用 Try 模式。此模式通过使用 out 参数返回函数的内容，并使用 bool 类型返回是否出现异常，以避免直接抛出异常。
举例来说，C# 中有 DateTime.Parse 和 DateTime.TryParse 两种方法。Parse 方法尝试将字符串解析为 DateTime 对象，如果解析失败，就会抛出异常。TryParse 方法也尝试解析字符串，但如果解析失败，它返回 false 并且不抛出异常。如果解析成功，它返回 true 并通过 out 参数返回解析结果。
string dateStr = "2023-07-11";
DateTime date;
if (DateTime.TryParse(dateStr, out date)) // "Try-Method"
{
Console.WriteLine("解析成功，日期是 " + date.ToString("yyyy-MM-dd"));
}
else
{
Console.WriteLine("解析失败，无法转换 '" + dateStr + "' 为日期");
}
Tester-Doer 模式与 Try 模式的对比
"Try" 模式是对 "Tester-Doer" 模式的进一步优化，它将 "Tester" 和 "Doer" 整合到一个方法中。这个方法尝试执行一个操作，并返回该操作是否成功。如果操作成功，它还会返回操作的结果。这种模式的优点是避免了两次方法调用的开销（一次 "Tester"，一次 "Doer"），并且可以预防 "race condition" 的问题。
让我们以一个在线银行应用为例。用户可以通过此应用进行转账操作。现假设我们按照
"Tester-Doer" 模式实现了如下代码：
// "Tester"
if (account.Balance >= amount)
{
// "Doer"
account.Balance -= amount;
otherAccount.Balance += amount;
}
如果我们使用 "Try-Method" 模式，我们可以将余额检查和转账操作作为一个原子操作，如下：
public bool TryTransfer(decimal amount, Account otherAccount)
{
lock (balanceLock)
{
if (Balance >= amount)
{
Balance -= amount;
otherAccount.Balance += amount;
return true;
}
else
{
return false;
}
}
}
在此例中，我们使用了 lock 关键字来确保在检查余额和进行转账操作之间，没有其他线程能改变账户余额。这样可以避免 "race condition"，确保账户余额的正确性。
总的来说，'Tester-Doer' 模式和 'Try' 模式都是为了预防性地处理异常，而不是在异常发生后进行处理。这两种模式各有优势，'Tester-Doer' 模式易于理解和维护，适用于大部分情况，而 'Try' 模式对性能的影响更小，特别是在需要频繁调用的情况下。
何时抛出异常
决定何时抛出异常时，我们需要界定异常是否代表的是使用错误（usage error）还是执行错误（execution error）。
使用错误（Usage Errors）：这类错误指出程序员没有正确使用API或方法。例如，传递了无效的参数或在错误的上下文中调用了方法。这类错误应该在开发和测试阶段被检测并修复。
执行错误（Execution Errors）：这类错误表示在尝试执行某些操作时发生了一个意外的状况。这种状况并非由于程序员的错误，而是由于某些无法预测的运行时状况导致，如网络中断、磁盘空间不足，或数据库连接失败等等。这类错误需要在运行时捕获并适当处理。
使用错误（Usage Errors）
“使用错误”通常指的是程序员因为编程错误或误解导致的问题。例如，可能传递了错误的参数，或在错误的上下文中调用了方法。这些错误通常在编译阶段就能被检测和修复，因此没有必要在运行时捕获和处理这些错误。
以下例子可以说明：
public class MyClass
{
public void MyMethod(string arg)
{
if (arg == null)
{
throw new ArgumentNullException(nameof(arg));
}
// 使用 arg 执行某些操作...
}
}
public class MyApp
{
public void Run()
{
var myClass = new MyClass();
myClass.MyMethod(null); // 这将引发一个使用错误（ArgumentNullException）。
}
}
MyMethod 期望 arg 参数不为null。但是，在Run 方法中，我们错误地传递了一个null值给 MyMethod。当 MyMethod 被调用时，它会抛出一个 ArgumentNullException，表示这是一个使用错误。对于这种错误，我们不应在运行时捕获并处理这个异常。相反，我们应修复 Run 方法，以确保我们永远不会传递一个 null 值给 MyMethod。这是一个编程错误，应通过修改代码来修复，而非通过异常处理。
下面是修改后的代码：
public class MyApp
{
public void Run()
{
var myClass = new MyClass();
var arg = "一些有效的值";
// 现在我们保证我们永远不会传递一个null给MyMethod。
// 这修复了编译时的使用错误，因此在运行时永远不会发生。
myClass.MyMethod(arg);
}
}
MyMethod 传递 null 值。这样就避免了在运行时抛出 ArgumentNullException 的使用错误。执行错误（Execution Errors）
执行错误可以进一步划分为程序错误和系统失败。
程序错误（Program Error）: 这种类型的错误是由程序的内部错误或逻辑错误引起的。例如，算法错误、数据结构问题、资源泄露等。这类错误通常可以通过更好的设计和编程技术来避免。
系统失败（System Failure）: 这种类型的错误是由外部系统引起的，比如硬件故障、网络中断、数据库连接失败、外部服务不可用等。对于这类错误，你的代码无法直接控制或预防，只能通过异常处理来应对。
1.程序错误（Program Error）
程序错误是一种可通过编程方式处理的执行错误。即便错误在运行时发生并非由编程错误引起，我们仍然可以通过编写适当的错误处理代码来将其返回正常流程。
以下是一个例子，说明了如何处理 File.Open 抛出的 FileNotFoundException，也就是一个典型的程序错误：
public FileStream OpenOrCreateFile(string filePath)
{
try
{
return File.Open(filePath, FileMode.Open);
}
catch (FileNotFoundException)
{
// 如果文件不存在，我们可以在这里创建一个新文件。
return File.Create(filePath);
}
}
File.Open 方法会抛出一个 FileNotFoundException。我们捕获这个异常，并在异常处理代码中创建一个新文件，这样处理这种情况，使其返回正常流程。2.系统失败（System Failure）
系统失败指的是无法通过编程手段处理的执行错误。这是因为这类错误通常由程序运行环境或系统资源的问题引起，这些问题超出了程序员的控制范围。
例如，当 Just-in-Time (JIT) 编译器因为内存耗尽而抛出 out-of-memory 异常时，这就是一个典型的系统失败。在这种情况下，尽管程序的代码逻辑可能是完全正确的，但由于环境问题（即内存不足）仍然发生了错误。
通常，对于系统失败，最好的策略是让程序终止，然后依赖外部机制（如操作系统或人工干预）来恢复或处理错误，因为这类错误超出了程序的处理能力。
以下是一个可能会导致 OutOfMemoryException 的示例：
try
{
// 尝试分配大量内存
var list = new List<long>();
for (int i = 0; ; i++)
{
list.Add(i);
}
}
catch (OutOfMemoryException)
{
// 对于这种严重的系统错误，我们应该立即终止程序。
Environment.FailFast("Out of memory!");
}
在这个例子中，程序试图无限制地分配内存，这在任何实际的系统中都是无法实现的，所以最终会导致 OutOfMemoryException。
尽管你可以在程序中捕获这个异常，但通常无法有效地处理它，因为在内存耗尽的情况下，你的程序可能无法进行任何有效的操作。
因此，对于这类系统失败，最好的处理方式通常是让程序终止，并依赖于外部机制来恢复或处理错误，如人工干预或系统的自动恢复机制。
Catch 块：异常捕获
catch 语句块用于实现错误的恢复代码。只有当你理解了为什么在特定的上下文中抛出了特定的异常，并且你能用编程方式来恢复失败的操作时，你才应该去捕获这个异常。也就是说，如果你无法确定如何从异常中恢复，那你就不应该去捕获这个异常。
按照我们之前的分类，我们应该只在发生程序错误的情况下捕获异常。
通过一个代码示例，我们可以更好地理解这个概念：
try
{
// 在此处尝试打开一个文件
var text = File.ReadAllText("myFile.txt");
}
catch (FileNotFoundException e)
{
// 如果文件不存在，我们就会知道为什么会抛出 FileNotFoundException。
// 并且，我们知道如何从这个异常中恢复：我们可以创建一个新的文件或使用默认的配置
File.WriteAllText("myFile.txt", "default content");
}
在这个例子中，我们尝试从 myFile.txt 文件中读取内容。如果文件不存在，File.ReadAllText 方法将会抛出一个 FileNotFoundException 异常。在 catch 块中，我们捕获了这个特定的异常，因为我们清楚导致异常的原因（文件不存在）以及如何从此异常中恢复（创建一个新文件并写入默认的内容）。
避免过度捕获异常
很多时候，我们应该允许异常向调用栈的上层传递，因为这有助于我们发现并修复程序中的错误。过度捕获异常可能会隐藏程序中存在的问题，这对于开发稳定的产品是极其不利的。因此，我们应当尽量减少异常处理的使用，除非我们确实需要它。
让我们通过一个代码示例来理解这个概念：
try
{
// 这里可能会抛出多种异常，如 FileNotFoundException、OutOfMemoryException 等
var text = File.ReadAllText("myFile.txt");
}
catch (Exception e)
{
// 我们捕获了所有的异常，这可能会掩盖一些我们未意识到的错误
Console.WriteLine("发生错误: " + e.Message);
}
在这个例子中，我们尝试读取一个文件的内容，但我们捕获了所有类型的异常，这可能会掩盖程序中的一些错误。比如，如果文件不存在，File.ReadAllText 方法会抛出 FileNotFoundException，我们可以通过创建一个新文件来处理这个异常。但如果抛出的是 OutOfMemoryException，我们可能无法处理，应让它继续向上抛出，由更高级别的代码或者最终的用户来处理。
因此，更好的做法可能是只捕获我们知道如何处理的特定异常：
try
{
var text = File.ReadAllText("myFile.txt");
}
catch (FileNotFoundException)
{
// 处理 FileNotFoundException，例如创建新文件
File.WriteAllText("myFile.txt", "default content");
}
// 其他异常（如 OutOfMemoryException）会继续向上抛出
Finally 块：确保资源的正确释放
异常处理中的 catch 子句用于恢复错误，而 finally 子句则负责执行清理代码。
操作如文件、数据库连接、网络连接等涉及占用系统资源的任务时，任务完成后我们需要进行适当的关闭或释放操作。这是因为这些操作会占用系统资源，如果不进行适当的关闭或释放，可能会导致系统资源的浪费，甚至在某些情况下，系统可能无法打开更多的文件或连接。
在编写异常处理代码时，我们往往更倾向于使用 try-finally 结构，而不是 try-catch 结构。尽管这看起来可能违反直觉，但事实上，在许多情况下，catch 块可能并不是必须的。这是因为 finally 块能够确保即使发生异常，清理代码也会被执行。这样做有助于我们确保即使在抛出异常后，系统也能维持一致的状态。通常来说，这个清理逻辑会涉及到撤销资源分配。
下面的代码示例能更好地说明这个概念：
FileStream stream = null;
try
{
stream = File.Open("myFile.txt", FileMode.Open);
// 对文件进行操作
var text = new StreamReader(stream).ReadToEnd();
Console.WriteLine(text);
}
catch (FileNotFoundException)
{
// 处理异常
}
finally
{
// 不论是否发生异常，总是关闭流
if (stream != null)
{
stream.Close();
}
}
finally 块中关闭 FileStream，那么当 try 块中的代码抛出异常时，stream.Close() 就不会被执行。此时，文件将被程序占用，直到程序结束。然而，通过在 finally 块中关闭 FileStream，我们确保了无论是否发生异常，文件都会被正确地关闭。Using 语句
C# 和 VB.NET 提供了 using 语句，用于清理实现了 IDisposable 接口的对象。它本质上就是一个 try-finally 语句。
我们通过一个代码示例来理解这个概念：
using (var stream = File.Open("myFile.txt", FileMode.Open))
{
// 这里可能会抛出异常
var text = new StreamReader(stream).ReadToEnd();
Console.WriteLine(text);
} // 在此处，即使抛出了异常，文件流也会自动关闭
在这个例子中，我们使用了 using 语句，它会自动调用 stream 对象的 Dispose 方法来关闭文件流，无论 using 块中的代码是否抛出异常。这样，我们就无需手动编写清理代码，可以更简洁、安全地处理资源。
总结
异常处理在编程中至关重要。它识别和处理程序中的错误条件，保持程序的稳定性和可靠性。异常处理改变程序的正常流程，并采取适当措施处理异常情况。
本文介绍了正常流程和异常流程的区别，以及异常对程序的影响。我们了解了面向对象语言中的异常处理原理，使用异常对象传播异常并通过 try/catch 块处理。
预防性处理异常的技巧包括 Tester-Doer 模式和 Try 模式，提高性能和健壮性。使用 finally 块和 using 语句清理代码和释放资源。
正确处理异常提升程序的可靠性、稳定性和性能。理解异常处理原理和应用技巧，编写健壮、可靠且易于维护的程序。
👉 欢迎加入小哈的星球 ，你将获得: 专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡
目前, 正在星球内部带小伙伴做第一个项目：前后端分离博客，手摸手，后端 + 前端全栈开发，从 0 到 1 讲解每个功能点开发步骤，1v1 答疑，直到项目上线。目前已更新了67小节，累计10w+字，讲解图：513张，还在持续爆肝中.. 后续还会上新更多项目，如秒杀系统, 在线商城, IM即时通讯等，戳我加入学习，已有200+小伙伴加入
1. 告别复杂逻辑，项目终于用上了 Spring 状态机，非常优雅！
2. 微软发布史上最强虚拟机！流畅度堪比主机（附保姆级安装教程）
最近面试BAT，整理一份面试资料《Java面试BATJ通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：点“在看”，关注公众号并回复 Java 领取，更多内容陆续奉上。
PS：因公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。
点“在看”支持小哈呀，谢谢啦